Well, I still haven't found the problem that causes TOS to fail
to be able to read the hard disk after running the recent
versions of SafeTT which talk to SCSI... but I did notice another
problem while looking through the dmaread.s code that Allan sent
me. 
 
After you have successfully selected a SCSI target, you need to
be careful about what you do after a "time-out." Imagine a slow
SCSI device (like our new CD-ROM, the CDAR-505).  It has an
average access time of 350 mS, and a worst case access time of a
little over 1 second.  It will respond to your read command
block, but you will time-out waiting for the first data byte.  At
that point it looks like your code just returns signaling an
error.  But the SCSI device will still be on the bus! Once
selected, SCSI assumes that you trust the target to moderate the
transfer...  to tell you the current bus phase and therefore
control the number of bytes passed.  The target doesn't know
you've lost interest. 
 
I'm not sure that the time-out code is a good idea beyond the
selection phase.  If you do want to have time-outs here to guard
against degenerate cases, I believe you are going to have to
reset the SCSI bus after you detect one of these time-outs.  If
you aren't going to walk through all the SCSI phases
giving/taking bytes as indicated to get the selected target back
to the IDLE state, SCSI RESET is the only alternative.  (And
doing a SCSI RESET is a bit fascist, since you can't be sure it
won't clear some desired state in a different SCSI device.)

It might also be a good idea for _resetscsi() to read from the
5380's reset error/interrupt register (#7) before returning to
clear the SCSI reset interrupt request... should anyone ever want
to use interrupts for watching the 5380.




From ajc!jwt Wed Jul 24 02:58:45 1991
Received: by atari.UUCP (4.12/4.7)
	id AA24944; Wed, 24 Jul 91 02:58:36 pdt
Received:  by ajc (UUPC/extended 1.10a);
           Wed, 24 Jul 1991 15:38:20 JST
Date:      Wed, 24 Jul 1991 15:38:17 JST
From: (Jim Tittsler) ajc!jwt
Message-Id: <288d205d@ajc>
Organization: Atari Japan Corp
To: atari!minna
Cc: atari!apratt
Subject:   dmaread.s
Status: RO

I believe the cache flushing code at "rw1:" has the wrong
conditional assembly flags guarding it (although admittedly as
currently set up SCSI == TT) and happens more than it needs to. 

You only need to flush the cache when DMA input has happened.(1)
DMA output (i.e.  writes) can never cause a loss of cache coherency,
nor can data transferred under processor control (which is how
the SCSI code is handled here). 

As dmaread.s is currently set up, the only time you need to flush
the cache is after an ACSI DMA read (on a TT).

But, its not the bug I was looking for.  Sigh.

______
(1) Since the 68030's cache controller does not monitor what
other system bus masters do, DMAing into external memory changes
the data there without changing any copies of those locations
that might already be in the internal cache.  "Flushing" the
cache is the quickest way to mark the internal contents as
invalid so stale data can't possibly be used.

